Note: this rule is using typescript-eslint/typescript-eslint#3658

May want to wait for typescript-eslint/typescript-eslint#1758 to be fixed too.

If upstream takes too long to resolve the issues/PRs, we can copy-paste in the relevant code to our repo in the meantime.

What would be the use-case for checking that types are not readonly? I like the dualism vs checking for readonly but I think we might introduce functionality that is not needed to encourage functional paradigms. My concern is mainly that it might make it more difficult to refactor/change things in the future as we may need to continuously support this functionality whether it is used or not.

I think it would be enough to support emulation of a mutable attribute by naming convention. This would probably only be needed on the variable or field level. Compare how it works in reasonml.

I did probably set this rule up to a little more that it needs to.

The intent was so that it could not only check for readonly types like prefer-readonly-type does, but would also be able to be configure such that it would be able to enforce type readonlyness in a consistent way as with how typescript internal types are named. That is to say, Array has ReadonlyArray, Set has ReadonlySet and Map has ReadonlyMap.

Thus the following use-case would be allowed (with some configuration, not by default):

type MyType = {
  foo: string;
  bar: string;
  readonly baz: string;
}

type ReadonlyMyType = {
  readonly foo: string;
  readonly bar: string;
  readonly baz: string;
}

The rule would be able to flag MyType if it was fully readonly; as if that was the case, it should be marked as a Readonly type.

Closed in favor of #259